Chapitre 14 [dev] - Développer en collaboration sur un projet git avec GitLab et RStudio

Déroulement du développement pour tous les [Dev].

14.1 Récupérer le projet depuis le serveur GitLab

Cloner avec RStudio :

  • File > New Project > Version Control > Git
    • Indiquer l’URL du dépôt git que vous récupérez sur GitLab
    • Choisir le lieu de stockage de ce projet sur votre ordinateur
    • Create Project
  • RStudio vous demande éventuellement votre mot de passe de connexion à GitLab
  • RStudio télécharge le contenu du projet, et lance le projet
  • Dans le cas d’un projet mis en place avec {renv}, vous devrez probablement mettre à jour votre installation locale de packages. Cette installation ne vaut que pour le projet en cours. Assurez-vous d’avoir la bonne version de R comme définie par les [ChfDev]
renv::consent(provided = TRUE)
renv::restore()

14.1.1 Gérer les caractères de fin de ligne

Le développement sur différents OS nécessite de gérer les caractères de fin de ligne, différents entre Windows et Linux/MacOS

  • Merci de fixer les caractères de fin de ligne à “POSIX (LF)” par défaut dans Rstudio dans les options globales (menu Tools / Global Options / Code / Saving / Serialization)
  • Un fichier nommé “.gitattributes” devrait par ailleurs exister dans le dépôt prenant en charge ce même problème.

14.2 Choisir son ticket entre le Kanban et le Chat

  • En discuter sur la plateforme de Chat avec les [ChfDev], repérer les priorités.
  • Chaque développeur ne travaille que sur un seul ticket à la fois, sauf cas exceptionnel. Toutefois, dans les commit, on pourra mentionner d’autres tickets si le travail a une influence identifiée sur les autres tickets.
  • Mettre son ticket dans la colonne En cours.
  • Retenir le numéro de son ticket pour en référer dans les messages de commit.

14.3 Gestion des branches du git : GitLab-flow et branches-issues

La gestion des branches de git se fait en suivant un format de type GitLab-flow :

  • master : La branche “master” est la branche principale de développement, celle vers laquelle toutes les branches vont converger. Note: vous pouvez nommer cette branche “main”.

  • production : La branche “production” ne doit contenir que les versions “fiables” du projet. Celles que l’on livre, qui sont mises en production et a priori taguées. Les [ChfDev] mettent en place cette branche au lancement du projet depuis GitLab :

    • Repository > Branches > New branch : “production”
    • Create from master

  • branches-issues : Les développeurs créent des nouvelles branches à partir de “master”
    • Le nom de la branche contient le numéro de l’issue (ticket/cas/question) à régler
    • Rapatrier les modifications critiques depuis “master” vers les branches avec un cherry-pick si nécessaire (si la MR indique qu’il y a des conflits par exemple), puis seulement, demander la fusion vers “master”.
    • Plus courtes seront les modifications de branches, plus facile sera la fusion dans le “master”
    • Privilégier de nombreuses “branches-issues” avec des petites issues à traiter, quitte à les subdiviser.

14.3.1 Présentation d’un GitLab Flow complet

Branche master et branches-issues

Figure 14.1: Branche master et branches-issues

Branche de production

Figure 14.2: Branche de production

14.3.2 Comment créer sa branche-issue depuis “master”

Vous développez dans une branche-issue avec un nom explicite, par exemple : 11-creer-table-1. 11 étant le numéro de l’issue que vous voulez traiter. Vous ferez en sorte d’être le plus à jour possible avec la branche “master” avant d’envoyer vos modifications sur le serveur et de régler les éventuels conflits en local par vous mêmes.

Pour créer votre “branche-issue”, vous pouvez le faire avec l’interface GitLab ou en ligne de commande en local.
L’interface GitLab permet en effet de créer une branche à partir d’un ticket.

  • Aller sur le ticket que vous voulez traiter
  • Cliquer sur “Create Branch” (ou “Créer la branche”)
  • Vous pouvez aussi directement créer une merge request en même temps que la branche
    • La merge request passera en mode “Draft”. Il faudra en changer le titre et retirer le “Draft” pour qu’elle puisse être fusionnée.
  • La branche créée contient le numéro du ticket et le titre de l’issue. Cela créé donc directement la nomenclature qui nous intéresse
  • Récupérer sa “branche-issue” en local
    • git pull
    • git checkout 11-titre-issue

Vous pouvez aussi créer la branche en local depuis la branche “master”, dans votre Terminal.

  • S’assurer d’être dans la branche “master” à jour
    • git checkout master
    • git pull
  • Créer une nouvelle branche avec le nom adapté
    • git checkout -b 11-corriger-ceci
  • Commencer votre développement

L’onglet “git” de l’interface graphique de RStudio ne gère pas toujours très bien la liste des branches, c’est souvent plus propre de créer la branche depuis GitLab que depuis RStudio.

Note: Une branche ouverte : l’issue change de tag Kanban. Elle est déplacée vers la colonne En cours

14.4 Rédiger un message de commit informatif

On commit souvent, on push en connaissance de cause

  • Faire un commit avec des explications claires
    • Proposition première ligne: ma_function: ajout/correction/fix fonctionnalité
      • Elle commence par une majuscule
      • Elle ne doit pas finir par un point
      • La phrase est écrite à l’impératif (e.g. « Clean your room »)
      • Elle ne doit pas dépasser 50 caractères
    • Une ligne vide sépare le sujet du contenu du message
    • Le contenu du message ne doit pas dépasser 72 caractères par ligne
    • Le contenu explique le «quoi» et le «pourquoi», mais pas le «comment»
    • Lister les issues sur lesquelles vous avez travaillé : #1
    • Voire les fermer avec closes #1 ou closes issue #12
knitr::include_graphics("images/projet-gitlab_22-close-issue-1-commit.png")

  • Il peut être utile de définir le template git de manière automatique :
    • git config --local commit.template path/to/file
    • Le template peut être le suivant :
# Define a direct explicit title

Why:

*

This change addresses the need by:

*
# 50-character subject line 
# 72-character wrapped longer description.

Issues
# List corresponding issues of your git manager

14.5 Comment se maintenir à jour avec la branche master

Les [ChfDev] ont définit un mode de fusion de branches au moment de la mise en place du projet dans la section “Choisir un mode pour les Merge Requests” qu’il est recommandé de lire pour bien comprendre la suite. Quelque soit le mode, il est recommandé de travailler avec une version la plus proche possible de la branche “master”. Pour cela, il vaut mieux faire plusieurs branches pour résoudre des petits problèmes et faire des Merge requests le plus souvent possible. La création de nouvelles branches permet aussi de partir d’une version récente du “master” et donc d’avoir les dernières nouveautés.

À chaque mise à jour du “master”, les [ChfDev] doivent prévenir tout le monde sur la plateforme de Chat. Vous veillerez à mettre à jour votre version locale du “master” avec un git fetch. Pensez aussi à regarder les Merge Request qui ont été fusionnées pour vous assurez qu’il n’y a pas de conflits potentiels sur les fichiers sur lesquels vous travaillez. Dans tous les cas, une demande de fusion rapide réduira les risques.

Dans le cas où vous ne pouvez pas faire une Merge Request dès la découverte d’un potentiel conflit, vous pouvez récupérer les commits potentiellement problématiques avec git cherry-pick <sha1>. Résolvez les conflits sur votre branche. Lorsque c’est résolu, vous devrez prévenir les [ChfDev] dans votre Draft de Merge Request que vous avez fait du cherry-pick.

Les [ChfDev] devront alors gérer la MR en local, avec un rebase avant la fusion:

git fetch
git checkout la-branche
git rebase origin/master
git checkout master
git merge --no-ff la-branche
git push

En théorie, si les conflits ont été résolus par cherry-pick, il ne devrait pas y avoir de nouveau conflit au rebase

14.5.1 Maintenir {renv} à jour

Si vous travaillez avec {renv}, à chaque fois que vous récupérez des commits depuis le serveur, il est possible que les autres développeurs aient changés les versions des packages R à utiliser.

  • Mettre à jour vos packages
renv::restore()
  • Vérifier que cela n’a pas de conséquences sur vos développements en cours en faisant tourner vos exemples reproductibles et le check
devtools::check()

14.6 Développer un package avec la méthode Rmd first

Les étapes de développement sont décrites plus en détail dans “Développer un package documenté et testé avec la méthode ‘Rmd first’”. D’une manière générale, il s’agit de :

  • Toujours développer dans un format package R
  • Développer dans une vignette reproductible
  • Créer les exemples reproductibles, la documentation et les tests unitaires en continu pendant le développement des fonctionnalités
  • Mettre en format package et faire passer les tests de conformité du package

Les tickets sont théoriquement définis pour que votre temps de développement soit court avant de pouvoir intégrer vos fonctionnalités à la branche dev. Vous pouvez donc conserver les commit en local en attendant d’être prêts à les envoyer sur le serveur. Généralement on n’envoie ses modifications sur le serveur que lorsqu’on est sûrs, après avoir discuté avec les [ChfDev] que notre branche est bien en mode fast-forward par rapport au dev et que la fusion sera la prochaine sur la liste. De cette manière, si vos modifications sont présentes uniquement sur votre ordinateur, vous pouvez toujours faire des rebase pour intégrer toutes les mises à jour de dev et ainsi vous assurez qu’il n’y a pas de conflits.

Bien sûr, votre développement peut prendre plus de temps que prévu, vous pouvez être stressés que votre code disparaisse s’il n’est pas sauvegardé sur le serveur distant. Dans ce cas, vous pouvez envoyer vos modifications au fur et à mesure. Cela a une autre avantage, c’est que l’intégration continue sera là régulièrement pour vous rappeler à l’ordre si vous avez oublié des étapes. Au moment de la demande d’intégration dans dev, vous serez probablement amenés à faire une copie de votre branche, pour la rebase et ainsi envoyer une branche en mode fast-forward avec les toutes dernières modifications qui ont été apportées par vos collaborateurs. Ceci dit, si vous attendez trop longtemps avant de faire une demande d’intégration dans dev vous risquez de devoir résoudre de nombreux conflits.

Il vaut mieux faire des demandes d’intégration dans dev régulières, quitte à subdiviser votre ticket en sous-parties de façon à ne pas perdre le fil. Et ce, même si l’intégration intermédiaire ne permet pas de terminer les demandes de votre ticket.

14.7 Intégrer les modifications à la branche “dev”

Si vous travaillez avec {renv} et avez installé ou mis à jour des packages lors de votre développement, vous devrez mettre à jour le fichier "renv.lock" avant d’envoyer vos modifications sur le serveur.

renv::snapshot()

Ou suivre les recommendations des [ChfDev] dans le fichier “dev/dev_history.R”

14.7.1 Vérification de l’intégration continue

L’intégration continue permet de tester la bonne installation du package dans un environnement vierge à l’intérieur d’un conteneur Docker (environnement stable pour l’exécution d’une version donnée). Avant d’ouvrir une Merge Request, vous devrez vous assurer que votre branche passe les tests de l’intégration continue.

  • L’intégration continue a été activée sur GitLab à la création du projet
    • Les instructions sont dans le fichier “.GitLab-ci.yml”
  • Les tests effectués sont ceux de devtools::check()
    • Installation des dépendances et du package
    • Création des vignettes
    • Tests des exemples des fonctions
    • Tests unitaires
  • S’assurer que les _commit_s et les MR passent l’intégration continue

14.7.2 Fusion dans dev par les [ChfDev]

Vous devez faire une demande de fusion, Merge Request pour ajouter vos fonctionnalités à la branche dev. Voici à quoi ressemble la page d’une Merge Request sur GitLab :

Les responsables du projet [ChfDev] révisent les modifications Ce sont les seuls qui normalement ont une vision d’ensemble des commit et donc de la manière de résoudre les conflits si besoin

  • Explorer le contenu des modifications avant fusion dans la partie “Changes” comme dans l’image suivante :
  • Si besoin, importer la branche en local pour faire passer les tests et apporter des modifications
  • Résoudre les conflits en local. Utiliser les lignes de commandes proposées par GitLab ou suivre la procédure de rebase
  • Discuter avec les [Dev] dans les commentaires de la MR si besoin
  • Accepter la Merge Request, en accord avec votre stratégie de fusion en cliquant sur le bouton de “Merge” (cf. section Accepter les MR/PR):

  • Dans le tableau de bord GitLab, déplacer les tickets fixés sous l’étiquette (label) “À valider”
  • Une fois la fusion effectuée, prévenir tout le monde sur le logiciel de Chat dédié pour que chacun mette à jour sa branche. Lister éventuellement les points qui pourraient bloquer ou entraîner des conflits.

C’est à ce moment qu’on peut mettre ce genre de message, si vous êtes en stratégie “rebase” :

Faîtes un rebase de votre branche si et seulement si vous n'avez pas envoyé de commit sur le serveur qui ne sont pas déjà dans le dev ! `git pull`, `git add .`, `git stash` , `git rebase origin/dev`, `git stash apply`

14.8 Comment gérer et accepter les MR/PR

Vous l’avez aperçu dans la partie “Choisir un mode pour les Merge Requests”, il y a deux façons de travailler pour accepter les “merge requests / pull requests”, soit on fait du rebase, soit on fait du merge. Dans tous les cas, vérifiez et revérifiez. Ne faîtes pas une confiance aveugle au diff de git pour vous dire les modifications qui ont été apportées.

14.8.1 Recommendation : le rebase

La recommandation pour une prestation c’est de s’assurer d’être toujours en mode fast-forward, en tout temps, dans toutes les branches en cours de développement.

Et il faut que les modifications n’ait pas déjà été envoyées sur le serveur. Cela réduit les risques de pertes de code décidées par git sans votre accord, sur la base de la date des commits qui sont fusionnés. Pour cette méthode, il faut communiquer au maximum.

14.8.1.1 Pour les [Dev]

  • Avant d’envoyer sa branche sur le serveur distant, on remet à jour avec la branche dev
    • git fetch, ajouter les fichiers modifiés en stage, git stash, git rebase origin/dev, git stash apply dans le terminal Rstudio
    • On résoud les éventuels conflits. Il est possible que les mêmes conflits doivent être réglés de la même manière plusieurs lors du rebase. Ce n’est pas un bug de git.
    • On s’assure que notre package passe toujours les check() en local
    • On s’assure qu’on n’a pas perdu les fonctionnalités qu’on était en train d’ajouter
  • Demander la permission aux [ChfDev] sur le Chat pour avoir le droit d’envoyer sa branche sur le serveur et ouvrir une merge request directement, tant qu’on est en fast-forward
  • Une fois la MR acceptée, il faut prévenir tout le monde sur le Chat de faire un rebase de sa branche en cours de développement.
    • git fetch, git stash, git rebase origin/dev, git stash apply

Vous pouvez faire un développement qui va durer plusieurs jours. Dans ce cas, pour éviter de perdre votre travail, vous allez envoyer votre branche sur le serveur régulièrement, sans demander de MR.

  • Ne faites jamais un rebase d’une branche qui est déjà partie sur le serveur, vous risquez de tout casser !
  • Lorsque vous voulez revenir en fast-forward pour demander une MR, il faut créer une nouvelle branche en local à partir de votre branche
    • git fetch, git checkout ma-branche-en-cours, git checkout -b ma-branche-en-cours-rebase
  • Ensuite, il faut procéder au rebase
    • git fetch, git rebase origin/dev
  • Si vous avez des conflits à régler.
    • Ouvrir le fichier à conflit (en orange dans le git de RStudio)
    • Gérer le conflit
    • Sauver le fichier.
    • Cocher sa case dans le git de RStudio.
    • Quand tous les conflits sont réglés, faire un git rebase --continue
      • Peut-être qu’il y a besoin d’un git commit avant le ‘continue’
  • Il est possible qu’il y ait à régler plusieurs fois les mêmes conflits. C’est normal… Il faut le refaire, pas le choix
  • Éventuellement, si vous voulez revoir l’historique de votre branche, pour regrouper des commits parce que vous avez envoyé ça très vite un soir de peur de tout perdre, pour ajouter des infos aux commits passés, vous pouvez faire un git rebase --interactive
  • Cette nouvelle branche est fast-forward avec “dev”. C’est celle-ci que nous allons envoyer sur le serveur pour demande de fusion avec “dev”.
  • Pensez à revérifier que tout va bien sur cette branche (attachment::att_amend_desc() puis devtools::check())
  • Demander la permission d’envoyer sur le serveur pour faire une MR directement.
  • Supprimer la branche originale

14.8.1.2 Pour la révision des [ChfDev]

Pour l’acceptation de la MR, les choses deviennent plus simples. Cela n’empêche en aucun cas de vérifier que le développement des nouvelles fonctionnalités ne détruit pas l’existant.

  • Réviser la MR sur GitLab
    • Vérifier chaque ligne de code qui a changé dans la partie “Changes”
      • Dans la comparaison, vous pouvez comparer avec “master (base)” ou “master (HEAD)”.
        • base : c’est la version de master depuis laquelle vous êtes partis en créant votre branche
        • HEAD : c’est la version de master actuelle. Si jamais il y a eu des commits intégrés à master entre temps, vous pouvez vérifier ce qui va réellement changer. S’il y a des conflits, vous serez prévenus, mais parfois, il y a des modifications qui ne posent pas de conflits git, mais des problèmes de code. Notez que s’il y a des conflits, vous ne pourrez pas comparer avec HEAD, vous devrez entrer en mode résolution de conflits avec l’IDE ou en local.
    • Commenter au besoin
  • Il est recommandé de vérifier les MR en local. Revérifier bien les modifications apportées, ligne par ligne, mais aussi celle des lignes au-dessus et en-dessous de celles notées par le diff
    • En effet, il arrive régulièrement que des lignes soient dupliquées parce que le “merge” ne s’est pas rendu compte que certaines lignes avaient légèrement changées de place au cours des modifications précédentes. C’est peu courant avec la méthode rebase, mais on n’est pas à l’abri.
  • Les [ChfDev] peuvent donc récupérer la branche en local et apporter des modifications. Les [Dev] sont normalement passés à une nouvelle branche.
    • Prévenir les [Dev] si on travaille dans sa branche
    • Penser à git commit -m "Sauver temporairement mon travail" les travaux qu’on était en train de faire sur sa branche. Ce sera toujours possible d’amender le commit avec git commit --amend en revenant dessus plus tard ou git reset <sha1 précédent> pour remettre ses modifs en mode non commit.
    • Récupérer la branche à réviser avec git fetch, git checkout origin/la-branche-a-reprendre et envoyer ses modifications. On est toujours en fast-forward dans cette branche.
  • Dans le cas où il s’est passé autre chose, avec d’autres MR et qu’on n’est plus en fast-forward, il faut reprendre la procédure de copie et de rebase ci-dessus.
  • Prévenir les dev qu’ils doivent rebase avec “origin/dev”

14.8.2 Note sur le cherry-pick

Gérer un rebase complet, avec l’interactivité de git, avec votre gestionnaire de messages de commit (vim ?), lorsque vous avez beaucoup de commit à rebase peut s’avérer laborieux. Parfois, il vaut mieux repartir d’une base saine et ajouter nos modifications au fur et à mesure, sans stress. Le cherry-pick peut vous aider. Vous pouvez récupérer des commits sur n’importe quelle branche pour les mettre où vous voulez.

  • Faîtes un git log --oneline
    • Tapez q pour arrêter le défilement.
  • Retrouvez le numéro du dernier commit en commun entre votre branche et le “dev”
  • Notez les de vos commits depuis ce dernier commit
  • Créez une nouvelle branche à partir du dev à jour
    • git fetch, git checkout -b ma-branche-fraiche origin/dev
  • Ajoutez les commits de votre branche précédente un par un
    • git cherry-pick <sha1>
  • Gérez les éventuels conflits, testez que ça passe le check()
  • Vérifiez bien le diff et les lignes de code qui ont été choisies par git
  • Vérifiez s’il n’y a pas des lignes dupliquées au-dessus ou en-dessous de celles signalées par le diff. Ça arrive.
  • Ajoutez les autres commits de la même manière

Vous êtes en train de faire un rebase à votre rythme !

14.8.3 L’autre méthode : le merge

Il est recommandé de ne pas accepter de MR en mode merge avec l’interface graphique pour être sûr de ne rien perdre dans la bataille. git choisit pour vous la version et les fusions qui lui conviennent, sur des bases parfois floues. Du coup, faites en sorte de bloquer le mode merge en clic bouton des MR si jamais la branche n’est pas en fast-forward. Ça se passe dans les paramètres du dépôt.
Lorsqu’une branche n’est pas en fast-forward, GitLab vous propose une procédure. Voici ce qu’il se passe :

  • Review la MR sur GitLab
    • Vérifier chaque ligne de code qui a changée
    • Commenter au besoin
  • Le chef de projet récupère la branche en local pour la préparer au merge. Le [Dev] est normalement passé à une nouvelle branche.
    • Penser à git commit -m "Sauver temporairement mon travail" les travaux qu’on était en train de faire sur sa branche. Ce sera toujours possible d’amender le commit avec git commit --amend en revenant dessus plus tard ou git reset <sha1 précédent> pour remettre ses modifs en mode non commit.
    • Récupérer la branche à réviser avec git fetch origin, git checkout -b "la-branche-a-reprendre" "origin/la-branche-a-reprendre".
    • Vous pouvez apporter vos modifications sur cette branche au besoin et faire de nouveaux commit
  • Procéder à la fusion avec le “dev” en local
    • git fetch origin met à jour les branches distantes sur votre version du “distant” en “local”.
    • git checkout "origin/dev" permet d’ouvrir une version détachée de la branche “dev” qui va recevoir la fusion, une copie temporaire de dev
      • Cet HEAD détaché n’est pas nommé, il n’a pas de branche sur laquelle se raccrocher directement
    • git merge --no-ff "la-branche-a-reprendre" fait la fusion de “la-branche-a-reprendre” dans la version détachée du “dev”. Cela signifie que vous êtes dans la version temporaire du futur “dev” fusionnée avec la branche.
      • Si tout se passe bien, vous avez une fusion directe, avec un message de commit de merge à rédiger
      • S’il y a des conflits, il vous sera demandé de les régler (une seule fois, contrairement au rebase).
        • Régler les conflits. Un conseil, utilisez un logiciel de comparaison de ficher pour cela…
        • Éventuellement, apporter de nouvelles modifications. Elles seront à notifier dans le message du commit de merge.
        • Ajouter les fichiers qui étaient en mode “conflit” avec git add mon_fichier ou l’interface Rstudio
        • Faire git commit pour remplir le commit de merge
  • Réaliser tous les tests nécessaires pour vous assurer que cette version temporaire de “dev” fonctionne correctement: devtools::check() notamment.
  • Utilisez votre RStudio pour vérifier les modifications réellement apportées par votre commit de merge.
    • Vous pouvez aussi utiliser les fonctionnalités de comparaison de deux commits de Meld (cf. paragraphe suivant) ou Visual Studio Code au besoin.
  • Dans tous les cas, revérifiez bien les modifications apportées, ligne par ligne, mais aussi celle des lignes au-dessus et en-dessous de celles notées par le diff
    • En effet, il arrive régulièrement que des lignes soient dupliquées parce que le “merge” ne s’est pas rendu compte que certaines lignes avaient légèrement changé de place au cours des modifications précédentes.
  • Lorsque vous êtes sûr de vous, vous pouvez pousser le HEAD détaché directement dans la branche “dev”
    • git push origin "dev"
    • ou git push origin HEAD:dev selon la version de git
  • La merge request associée devrait s’être fermée automatiquement sur l’interface graphique.
  • Prévenez tout le monde et on reprend la procédure !

14.8.4 Comparer les versions de deux branches

Des interfaces graphiques peuvent vous permettre de comparer l’état de deux branches différentes. Très pratique pour vérifier les Merge Requests en local avant de les accepter !

14.8.4.1 {compareWith} et Meld

Le package {compareWith} permet d’ajouter des Addins à RStudio pour comparer des versions de vos branches : https://github.com/miraisolutions/compareWith.
Il nécessite l’installation de Meld.

  • Utiliser l’Addin : “Compare with repo - project” pour voir ce que vous avez modifié depuis le dernier commit ou pour régler les conflits de fichiers
  • Utiliser l’Addin : “Compare current with commit or branch…” pour comparer vos dernières modifications avec celles d’une autre branche du projet

14.8.4.2 Meld

git config --global diff.tool meld
  • Comparer deux branches complètes (e.g. production vs master)
git difftool --dir-diff production master

14.9 Sauver son mot de passe git dans le Terminal

Si vous faites des opération git directement dans le Terminal, vous aurez envie de sauver votre mot de passe git pour ne pas avoir à le taper à chaque push.

Dans ce cas, utilisez :

  • Pour Windows : git config --global credential.helper wincred
  • Pour MacOS : git config --global credential.helper osxkeychain
  • Pour Linux : git config --global credential.helper cache et augmenter le timeout git config --global credential.helper 'cache --timeout=3600' pour 1 heure.

Lorsque vous changez de mot de passe, sur Windows, il faudra aller le modifier dans le “Windows Credentials Manager” > “Windows Credentials” et modifier celui qui correspond.

14.10 Élaguer les branches mortes

14.10.1 Nettoyer les branches sur GitLab

Dans l’interface GitLab, il est possible de supprimer les branches qui n’ont pas été utilisées depuis longtemps et celles qui ont déjà été fusionnées.

  • Aller dans le menu “Repository” > “Branches”
  • Choisir l’onglet “Stale” ou “All”
  • Supprimer toutes les branches qui ont déjà été “Merged”
  • Faire le ménage sur les branches qui vous paraissent obsolètes

14.10.2 Nettoyer les branches “locales-distantes”

Les branches “local-distantes” sont les branches dans votre copie locale du serveur. Chaque nouvelle branche sur le serveur, lorsque vous faîtes un git fetch ou bien un git pull , est récupérée en local sur votre ordinateur. Vous pouvez ou non choisir de l’utiliser pour y apporter des modifications (git checkout <branch>). Lorsque ces branches sont supprimées du serveur, comme indiqué dans le paragraphe précédent, elles ne sont pas directement supprimées de votre ordinateur.

Pour faire le nettoyage, utiliser : git fetch -p

Notez que cette copie “locale-distante” peut avoir un intérêt pour récupérer une branche qui a été supprimée sur le serveur par mégarde, tant que vous n’avez pas fait le nettoyage.

14.10.3 Nettoyer les branches “locales-locales”

Sinon, il faudra faire un git branch -D nom_de_la_branche_supprimer1 nom_de_la_branche_supprimer2

Et pour les branches locales qui n’ont plus de parent à distance :

git branch -vv | grep ': gone]'|  grep -v "\*" | awk '{ print $1; }' | xargs -r git branch -d

Théoriquement, il vérifie que la branche en question a bien été fusionnée avant de la supprimer.
Sinon, il faudra faire un git branch -D nom_de_la_branche_supprimer1 nom_de_la_branche_supprimer2